home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 918 / text0000.txt < prev   
Encoding:
Text File  |  1996-08-06  |  2.1 KB  |  43 lines
  1. Tom Payne <thp@cs.ucr.edu> wrote:
  2. > Steve Clamage (clamage@Eng.Sun.COM) wrote:
  3. > : I don't see any advantage in trying to restrict the kind or form of checking
  4. > : that systems are allowed to implement. I would applaud a hardware-based
  5. > : mechanism, and I would resent a programming language standard that made
  6. > : it non-conforming.
  7. > The issue is not the form of the checking but the response to it.  The
  8. > standard response to a hardware-detected fault is to invoke a signal
  9. > handler, which is (or should be) completely conforming.
  10.  
  11. Consider this implementation with NO run-time pointer checking (as
  12. is allowed) where every object contains not only a vtable pointer
  13. but also an owner-task pointer as well, used for inter-process
  14. memory management.
  15.  
  16. Now, if we run out of normal registers and it is necessary to
  17. spill the "current task" register, its value can be reloaded
  18. through any register pointing at an object (say because register-
  19. indirect might be faster than absolute addressing). The compiler
  20. writer knows this will only be done if a valid pointer value is
  21. already in a register (and calling delete will invalidate the
  22. register), since it would be more economical to obtain the value
  23. some other way if a pointer to it isn't available).
  24.  
  25. However, using the value in an expression might cause a register
  26. to get re-loaded with that value, so that reloading the task
  27. pointer could go wrong; in a system with an unprotected memory
  28. space, corrupting the task pointer could indeed be the equivalent
  29. of "halt and catch fire".
  30.  
  31. Is there anything in such an implementation that is unconforming?
  32. If not, then I submit that "undefined behaviour" IS the correct
  33. term to apply to *any* use of an invalidated pointer value.
  34.  
  35. -Martin.
  36.  
  37.  
  38. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  39. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  40. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  41. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  42. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  43.